1. The Field of the Invention
The present invention relates to network communication technology, and more specifically, to mechanisms for controlling the admission of data streams onto a network.
2. Background and Relevant Art
Computer networks have enhanced our ability to communicate and access information by allowing one computer or device (hereinafter both referred to as a “computing system”) to communicate over a network with another computing system using electronic data. When transferring electronic data between computing systems, the electronic message will often pass through a protocol stack that performs operations on the electronic data. The Open System Interconnect (“OSI”) model is an example of a networking framework for implementing a protocol stack.
The OSI model breaks down the operations for transferring electronic data into seven distinct “layers,” each designated to perform certain operations in the data transfer process. While protocol stacks can potentially implement each of the layers, many protocol stacks implement only selective layers for use in transferring electronic data across a network. When electronic data is transmitted from a computing system, it originates at the application layer and is passed down to intermediate lower layers and then onto a network. When electronic data is received from a network it enters the physical layer and is passed up to higher intermediate layers and then eventually received at the application layer.
The application layer, the upper most layer, is responsible for supporting applications and end-user processes. An intermediate layer incorporated by most protocol stacks is the transport layer, which at the very least functions to multiplex application data into transport layer segments for delivery to lower layers and to demultiplex transport layer segments into application data for delivery to applications. The User Datagram Protocol (“UDP”) is an example of a protocol implemented at the transport layer that does little more than multiplex/demultiplex data for compatible transfer between applications and networks. Another common protocol implemented at the transport layer is the Transmission Control Protocol (“TCP”), a connection-oriented protocol that can also provide the features of end-to-end error recovery, resequencing, and flow control to the application layer.
Even on properly configured networks data loss can occur from time to time due to adverse network conditions, such as, for example, hardware component failures, software errors, link noise or interference, network congestion, etc. In may instances, the occurrence of adverse network conditions will be unknown to an user desiring to transmit electronic data across a network. Further, even if the user becomes aware of adverse network conditions, correcting the adverse conditions is often beyond the user's control. Thus, there is always some potential for data loss when electronic data is transferred across a network. Fortunately, the features of TCP can compensate for and correct data loss resulting from many adverse network conditions. Accordingly, TCP is extremely useful when reliable transfer of data is desired, such as, for example, when transferring a Web page with both text and graphics.
However, to realize the features of TCP, certain state information, such as, for example, receive and send buffers, congestion control parameters, and sequence and acknowledgment number parameters must be maintained for each TCP connection. Maintenance of state information consumes computing system resources (e.g., system memory) making these resources unavailable to user processes that might otherwise utilize the resources. Thus, when reliable transfer of data is not critical, applications may instead use UDP to conserve computing system resources when transmitting electronic data across a network.
UDP is particularly well suited for transferring audio and video data (hereinafter referred to as “A/V data”) as a steady and continuous stream (frequently referred to as “streaming”) between computing systems. Since output of A/V data typically includes refreshing previously received A/V data, some loss of A/V data (e.g., such as the inherent data loss in many networks) from an A/V data stream is not critical. For example, when video data for a video frame is not received, a display screen may appear to momentarily flicker but is then refreshed when updated video data is received. Accordingly, UDP is frequently used to transfer A/V data streams between computing systems in Home Network, Local Area Network, and Wide Area Network environments.
Unfortunately, UDP has no built in mechanism for congestion control. Thus, a computing system utilizing UDP to transmit an A/V data stream typically cannot detect when transmission of the A/V data stream is being degraded due to network congestion. Likewise, a computing system utilizing UDP to transmit an A/V data stream typically cannot detect when the A/V data stream is causing network congestion that degrades other A/V data streams. Thus, it may be that an A/V data stream is transmitted onto a network with other existing AN data streams thereby degrading the quality of all the AN data streams.
For example, when a 10 Mega-bit per second (“Mbps”) Ethernet Hub is supporting an existing 6 Mbps High Definition Television data stream and another 6 Mbps High Definition Television data stream is initiated, both data streams may suffer from high delay, jitter, and packet loss. Further, since the transmission speed of UDP is only constrained by the rate at which an application generates data and the capabilities of the source (CPU, clock rate, etc.), it would not be uncommon to have a number A/V data streams transmitting data at high data transfer rates at any given time. Although, TCP has a congestion control mechanism, the TCP congestion control mechanism is not well suited for real-time applications, such as, for example, those applications that transmit A/V data streams. The TCP congestion control mechanism reduces the data transfer rate when one or more data links between a sending computing system and a receiver computing system become excessively congested. However, reduction of a data transfer rate can significantly degrade real-time applications, which can tolerate some packet loss but require a minimum data transfer rate.
Additionally, when a network becomes congested, one A/V data stream may get a disproportionate amount of bandwidth (commonly referred to as the “Ethernet Capture Effect”). Thus, a newer A/V data stream could possibly “take-over” bandwidth from an existing A/V data stream. This may leave an existing user of the existing A/V data stream dissatisfied. An initiating user of the newer A/V data stream may not have actively desired to degrade the existing A/V data stream. However, the initiating user may have no way to determine if the network could support both A/V streams prior to initiating the newer A/V stream.
Further, a network administrator may have no mechanism to restrict A/V data streams or limit the amount of network bandwidth that can be consumed by A/V data streams. Many networks inherently give A/V data streams higher priority than other types of data because data lost from A/V data streams typically cannot be recovered. Thus, when congestion occurs on a network link, A/V data streams may be given bandwidth due to higher priority. Bandwidth given to an A/V data stream during congestion may reduce the bandwidth available to other non-streaming data, causing the transfer of non-streaming data to degrade. For example, transmission of an A/V data stream might delay, or even prevent, transmission of a Web page, when there is not enough bandwidth capacity to appropriately transmit both the A/V data stream and the Web page.
Therefore systems, methods, and computer program products for controlling the admission of data streams onto a network would be advantageous.